Bitstream structure for viewport-based streaming with a fallback bitstream

ABSTRACT

A method, computer program, and computer system is provided for splitting viewport bitstreams. A first coded video bitstream is at least partially encoded using a first Group-of-Pictures (GOP) structure at a first resolution. A second coded video bitstream structured into a plurality of tiles is encoded using a second GOP structure at a second resolution, whereby the second GOP structure includes fewer coded pictures than the first GOP structure. A streaming bitstream for decoding or rendering is created using the first coded video bitstream and the second coded bitstream.

CROSS REFERENCE TO RELATED APPLICATION

This application claims priority based on U.S. Provisional Application No. 63/030,856 (filed May 27, 2020), the entirety of which is incorporated by reference herein.

BACKGROUND

This disclosure relates generally to field of data processing, and more particularly to video streaming.

Immersive video streaming involved the transmission of a “world” or “omnidirectional” view from a sender to a receiver, and the receiver would render only parts of the received world-view based on, for example a viewport. The viewport can be selected based on direction of head movement when wearing virtual reality goggles. Viewport-dependent video streaming can relate to techniques where, out of a scene that was recorded covering a “world” view, only a portion of that view is being transmitted and rendered to the user based on the viewport the user has selected.

SUMMARY

Embodiments relate to a method, system, and computer readable medium for splitting viewport bitstreams. According to one aspect, a method for splitting viewport bitstreams is provided. The method may include encoding, at least partially, a first coded video bitstream using a first Group-of-Pictures (GOP) structure at a first resolution. A second coded video bitstream structured into a plurality of tiles is encoded using a second GOP structure at a second resolution, whereby the second GOP structure includes fewer coded pictures than the first GOP structure. A streaming bitstream for decoding or rendering is created using the first coded video bitstream and the second coded bitstream.

According to another aspect, a computer system for splitting viewport bitstreams is provided. The computer system may include one or more processors, one or more computer-readable memories, one or more computer-readable tangible storage devices, and program instructions stored on at least one of the one or more storage devices for execution by at least one of the one or more processors via at least one of the one or more memories, whereby the computer system is capable of performing a method. The method may include encoding, at least partially, a first coded video bitstream using a first Group-of-Pictures (GOP) structure at a first resolution. A second coded video bitstream structured into a plurality of tiles is encoded using a second GOP structure at a second resolution, whereby the second GOP structure includes fewer coded pictures than the first GOP structure. A streaming bitstream for decoding or rendering is created using the first coded video bitstream and the second coded bitstream.

According to yet another aspect, a computer readable medium for splitting viewport bitstreams is provided. The computer readable medium may include one or more computer-readable storage devices and program instructions stored on at least one of the one or more tangible storage devices, the program instructions executable by a processor. The program instructions are executable by a processor for performing a method that may accordingly include encoding, at least partially, a first coded video bitstream using a first Group-of-Pictures (GOP) structure at a first resolution. A second coded video bitstream structured into a plurality of tiles is encoded using a second GOP structure at a second resolution, whereby the second GOP structure includes fewer coded pictures than the first GOP structure. A streaming bitstream for decoding or rendering is created using the first coded video bitstream and the second coded bitstream.

BRIEF DESCRIPTION OF THE DRAWINGS

These and other objects, features and advantages will become apparent from the following detailed description of illustrative embodiments, which is to be read in connection with the accompanying drawings. The various features of the drawings are not to scale as the illustrations are for clarity in facilitating the understanding of one skilled in the art in conjunction with the detailed description. In the drawings:

FIG. 1 is a schematic illustration of the ecosystem for streaming a immersive video, according to at least one embodiment;

FIG. 2 is a schematic illustration of a viewport based streaming workflow of a immersive video, according to at least one embodiment;

FIG. 3 is a schematic illustration of fragmented immersive video bitstreams with a frame boundary, according to at least one embodiment;

FIG. 4 is a schematic illustration of viewport update during immersive bitstream playback with a frame boundary, according to at least one embodiment;

FIG. 5 is a schematic illustration of 8K and 2 k immersive bitstream fragmentations with a frame boundary, according to at least one embodiment;

FIG. 6 is a block diagram of a system for viewport bitstream splitting, according to at least one embodiment;

FIG. 7 is a schematic illustration of a computer system, according to at least one embodiment; and

FIG. 8 is an operational flowchart illustrating the steps carried out by a program for viewport bitstream splitting, according to at least one embodiment.

DETAILED DESCRIPTION

Detailed embodiments of the claimed structures and methods are disclosed herein; however, it can be understood that the disclosed embodiments are merely illustrative of the claimed structures and methods that may be embodied in various forms. Those structures and methods may, however, be embodied in many different forms and should not be construed as limited to the exemplary embodiments set forth herein. Rather, these exemplary embodiments are provided so that this disclosure will be thorough and complete and will fully convey the scope to those skilled in the art. In the description, details of well-known features and techniques may be omitted to avoid unnecessarily obscuring the presented embodiments.

Embodiments relate generally to the field of data processing, and more particularly to video streaming. The following described exemplary embodiments provide a system, method and computer program for, among other things, viewport-based video streaming. Therefore, some embodiments have the capacity to improve the field of computing by allowing for the splitting of a viewport bitstream into smaller fragmented files or segments of DASH and provide fallback bitstream fragments or segments for supporting fast bitstream random-access in playback.

As previously described, immersive video streaming involved the transmission of a “world” or “omnidirectional” view from a sender to a receiver, and the receiver would render only parts of the received world-view based on, for example a viewport. The viewport can be selected based on direction of head movement when wearing virtual reality goggles. Viewport-dependent video streaming can relate to techniques where, out of a scene that was recorded covering a “world” view, only a portion of that view is being transmitted and rendered to the user based on the viewport the user has selected.

However, when streaming an immersive bitstream, whenever the viewport changes, all the frames within the random-access point period need to be downloaded, irrespective of the position of viewport. Therefore, if the viewport lies in the middle of the random-access period, all frames within the access period (such as, for example, 30 frames) need to be downloaded and decoded. The tile bitstreams cannot be decoded from the middle of random-access point period. Hence, this adds latency. Additionally, downloading full frame pictures may cost more network bandwidth than it is necessary for user's field-of-view (FoV) playback and rendering. When streaming high resolution video, the segmentation may cause delays in bitstream downloading and rendering when network resources are less than ideal. Changes in viewer's FoV may also cause (additional) delay and degrade user's quality experience (QoE). It may be advantageous, therefore, to reduce the latency incurred when the viewport is changed in immersive video by restructuring the bitstream.

Aspects are described herein with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer readable media according to the various embodiments. It will be understood that each block of the flowchart illustrations and/or block diagrams, and combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer readable program instructions.

The following described exemplary embodiments provide a system, method and computer program that splits a viewport bitstream into smaller fragmented files or segments of DASH and provides fallback bitstream fragments or segments for supporting fast bitstream random-access in playback.

FIG. 1 illustrates a block diagram of an ecosystem 100 for streaming a immersive video. A 360 video (101) is passed through an encoder (102) and the entire picture is streamed over content delivery network (CDN) (103). The user decodes and reconstructs the received content (104) in the VR player (105). The downside of sending the entire picture is a waste of bandwidth and rendering resources since user's field-of-view (FoV) (106) at any given time only falls in to a contain degree. The bitstream which is out of the user's current FoV may not be viewed and is received and rendered by the client anyway. The viewport selection can, for example, be based on direction of head movement when wearing virtual reality goggles. Viewport-dependent video streaming can relate to techniques where, out of a scene that was recorded covering a “world” view, only a portion of that view is being transmitted and rendered to the user based on the viewport the user has selected, thereby eliminating the need to transmit the whole world-view.

Tile (or subpicture)-based immersive video streaming technology can be used to reduce the bandwidth requirements and improve the video quality of video playback. Referring to FIG. 2, a block diagram of a 360 viewport-dependent video streaming system 200 is depicted. A 360 video scene (201) is encoded by using a planar video encoder (202) after the video scene has been appropriately stitched and projected into a flat video using, for example, the equirectangular or cubemap projection.

In order to use a coded video bitstream over DASH, the sequence can be put into a file with a format that splits the bitstream into a sequence of smaller HTTP-based video bitstream segments. Those video files may have different bitrate and durations. They may be transmitted through an IP network and independently decodable in a client side.

An encoded immersive video may be fragmented by a DASH packager (203) as described above. The fragmented content may be saved in a content-delivery server (not depicted) and conveyed by a CDN (204), to a compatible player (205) for rendering (206). Here the transmitted video (209) consists only of high-resolution FoV (208) instead of sending the entire picture (207). At the receiver side, the 4K picture is decoded and reconstructed in the player.

Tile based streaming spatially partitions the 360 video frames into multiple tiles or blocks. Here, the panoramic video is encoded and divided into tiles after the compression state. The user then requests only the tiles that fall fully or partially into the user's field of view (FOV). By splitting large immersive video bitstream pictures into smaller fragments or tiles and transmit fragments or tiles which falls into user's FOV may save network and rendering side resources.

A large immersive content (after projection, e.g., the flat video stream) may be spatially subdivided into tiles of, for example, the same resolution. For example, a source picture of a 4 k×2 k video sequence may be split into equally sized tiles of 512×156 samples, resulting in 64 tiles. Each tile may be encoded and packaged at different bitrates and quality levels (e.g., in DASH), and may be requested at a quality different from its neighboring tile. The tiles in the user's viewport may be prioritized and streamed at a higher quality than tiles outside the viewport. In some cases, certain tiles may be omitted from transmission entirely. As a fallback, an extra layer with, for example a lower resolutions/quality/bitrate covering the entire panorama may be used. Assuming an appropriate player design, doing so may prevent visual artifacts, for example, black areas, when the FoV changes but the new tiles are not immediately available due to network/streaming server delay.

The resolution of the tiles may be changed when the user moves his/her head, but, for example only at random-access points (RAPs). A RAP can be an access unit at which the receiver can successfully start decoding the tile or video. The picture frames may be grouped together in a different GOP (Group of pictures) sizes. I-frames may be followed by P-frames which may contain a coded representation of the changes of the preceding frame. Therefore, P-frames are dependent on the I-frames and earlier P-frames. GOP structures are used in typical encoders which causes each I frame to be a random-access point such that decoding can start on an I frame. Therefore, the response time needed for the tile to be changed depends on the tile granularity and RAP distance. When the user's orientation changes, the tiles currently in viewport may need (at least partially) to be replaced by different tiles. These new tiles may only be switched at the next available RAP, resulting in a delayed reaction to user input.

Referring now to FIG. 3, a block diagram 300 of fragmented immersive video bitstreams with a frame boundary embodiment is depicted. For example, an 8 k (301-303) and 2 k (304-306) resolution video bitstream may be contained within a representation of the same projected scene. The low resolution (304-306) can be used as a fallback when changing the FoV, and may be streamed continuously. The high resolution (301-303) may be a tiled representation and may be used for viewport independent streaming as described above. Both streams may have the equal frame count and may be split into equal fixed-frame fragments, which may consist of a random-access point period of 30 frames. Only certain tiles of the 8K resolution are delivered as required to cover the FoV, while the entire frame with 2K resolution is delivered as fallback. RAPs may be present in each bitstream once every 1 second assuming a fixed 30 fps frame rate.

While such a configuration may allow visually pleasing fast reactions by the render using the reconstructed fallback bitstream in case of FoV change, the issue remains that on average 15 frames of high resolution tiles are being sent at each FoV change that are useless, as they may not be rendered due to the changed FoV.

Referring to FIG. 4, a block diagram 400 of viewport update during immersive bitstream playback with a frame boundary embodiment is depicted. Block diagram 400 illustrates emulating a FoV update while playback is in place. When the viewpoint changes to 402, the entire 403 frame is downloaded and decoded, besides 404 and 405, even if the viewport lies in the middle of the frame, since the I-frame (401) is located in the beginning of the frame. If the current network bandwidth is less ideal, downloading a new fragment with 8K resolution may cause extra delay.

Referring now to FIG. 5, a block diagram 500 of an 8K and 2 k immersive bitstream fragmentations with the frame boundary embodiment is depicted. The random-access point period may be reduced to, for example, one or more of 10 frames (e.g., 10 frames 501-508) for the high-resolution segments in the viewport. The first picture is encode as the I-frame and rest as P frame, and for the low resolution fall back, either only the first picture is encoded as I-frame and the following pictures as P-frames, or a fast random access with unequal random access periods should be defined.

When the random-access period is small, at the time the viewport changes, the client does not have to download all 30 frames, but only 10 frames. Therefore, the delay between the request of new viewport and rendering the new viewport is reduced since the random-access point period is reduced and more number of random access points are now available. A fallback bitstream 509 with a lower bitstream resolution may be provided for less ideal network situation. Of course, this increased efficiency is bought by the coding overhead of the additional random access pictures.

Referring now to FIG. 6, a block diagram of a viewport bitstream splitting system 600 is depicted. The content after being capture by the camera is stitched into a panoramic representation (601) and is then encoded (602) and passed through a low delay packager (603) where the bitstream is structured with reduced random-access point period. The transmitted video (609) contains high resolution content of the user's FoV (608) and reduced quality for rest of the picture (607). This content is conveyed via CDN (604) to a VR player (605) for rendering (606).

In one or more embodiments, the bitstream with a high resolution may have short segment sizes, while the bitstream with a low resolution may have long segment sizes. The segment size may be fixed for each bitstream, or the segment size may be changed within the entire bitstream.

In the same embodiment, the picture of the high resolution bitstream may cover some part or the entire region of the low-resolution picture. When two bitstreams are transmitted and decoded at the decoder size, hence, the low-resolution decoded picture may be up-sampled and blended with the high resolution decoded picture. When blended, some part or the entire region of the low-resolution decoded picture may be replaced by or averaged by the high resolution decoded picture.

In one or more embodiments, each segment of the bitstream may have one or more I-pictures, which are used for random access. The first picture of each segment may be an Intra Random Access Point (IRAP) picture that enables the random access at the point with the picture. The MAP picture may be IDR, CRA, BLA or GRA picture in AVC, HEVC, EVC or VVC.

In one or more embodiments, the server may have several bitstream with different segment sizes. For example, the first bitstream may have segment size equal to 30 frames, the second bitstream may have segment size equal to 20 frames and the third bitstream may have segment size equal to 10 frames.

In the same embodiment, when the viewport of the end user is slowly changed or the network bandwidth is not enough, the first bitstream with the long segment size (30 frames) may be transmitted to fit the actual bitrate to the target bitrate or improve the visual quality.

In the same embodiment, when the viewport of the end user is quickly changed or the network bandwidth is high, the second or third bitstream with the short segment size (20 or 10 frames) may be transmitted to order to quickly change the target view with a fast-random access.

The techniques for bitstream structure for immersive viewport-based video streaming, described above, can be implemented as computer software using computer-readable instructions and physically stored in one or more computer-readable media. For example, FIG. 7 shows a computer system 700 suitable for implementing certain embodiments of the disclosed subject matter.

The computer software can be coded using any suitable machine code or computer language, that may be subject to assembly, compilation, linking, or like mechanisms to create code comprising instructions that can be executed directly, or through interpretation, micro-code execution, and the like, by computer central processing units (CPUs), Graphics Processing Units (GPUs), and the like.

The instructions can be executed on various types of computers or components thereof, including, for example, personal computers, tablet computers, servers, smartphones, gaming devices, internet of things devices, and the like.

The components shown in FIG. 7 for computer system 700 are exemplary in nature and are not intended to suggest any limitation as to the scope of use or functionality of the computer software implementing embodiments of the present disclosure. Neither should the configuration of components be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary embodiment of a computer system 700.

Computer system 700 may include certain human interface input devices. Such a human interface input device may be responsive to input by one or more human users through, for example, tactile input (such as: keystrokes, swipes, data glove movements), audio input (such as: voice, clapping), visual input (such as: gestures), olfactory input (not depicted). The human interface devices can also be used to capture certain media not necessarily directly related to conscious input by a human, such as audio (such as: speech, music, ambient sound), images (such as: scanned images, photographic images obtain from a still image camera), video (such as two-dimensional video, three-dimensional video including stereoscopic video).

Input human interface devices may include one or more of (only one of each depicted): keyboard 701, mouse 702, trackpad 703, touch screen 710, data-glove (not depicted), joystick 705, microphone 706, scanner 707, camera 708.

Computer system 700 may also include certain human interface output devices. Such human interface output devices may be stimulating the senses of one or more human users through, for example, tactile output, sound, light, and smell/taste. Such human interface output devices may include tactile output devices (for example tactile feedback by the touch-screen 710, data-glove (not depicted), or joystick 705, but there can also be tactile feedback devices that do not serve as input devices), audio output devices (such as: speakers 709, headphones (not depicted)), visual output devices (such as screens 710 to include CRT screens, LCD screens, plasma screens, OLED screens, each with or without touch-screen input capability, each with or without tactile feedback capability—some of which may be capable to output two dimensional visual output or more than three dimensional output through means such as stereographic output; virtual-reality glasses (not depicted), holographic displays and smoke tanks (not depicted)), and printers (not depicted).

Computer system 700 can also include human accessible storage devices and their associated media such as optical media including CD/DVD ROM/RW 720 with CD/DVD or the like media 721, thumb-drive 722, removable hard drive or solid state drive 723, legacy magnetic media such as tape and floppy disc (not depicted), specialized ROM/ASIC/PLD based devices such as security dongles (not depicted), and the like.

Those skilled in the art should also understand that term “computer readable media” as used in connection with the presently disclosed subject matter does not encompass transmission media, carrier waves, or other transitory signals.

Computer system 700 can also include interface to one or more communication networks. Networks can for example be wireless, wireline, optical. Networks can further be local, wide-area, metropolitan, vehicular and industrial, real-time, delay-tolerant, and so on. Examples of networks include local area networks such as Ethernet, wireless LANs, cellular networks to include GSM, 3G, 4G, 5G, LTE and the like, TV wireline or wireless wide area digital networks to include cable TV, satellite TV, and terrestrial broadcast TV, vehicular and industrial to include CANBus, and so forth. Certain networks commonly require external network interface adapters that attached to certain general purpose data ports or peripheral buses (749) (such as, for example USB ports of the computer system 700; others are commonly integrated into the core of the computer system 700 by attachment to a system bus as described below (for example Ethernet interface into a PC computer system or cellular network interface into a smartphone computer system). Using any of these networks, computer system 700 can communicate with other entities. Such communication can be uni-directional, receive only (for example, broadcast TV), uni-directional send-only (for example CANbus to certain CANbus devices), or bi-directional, for example to other computer systems using local or wide area digital networks. Certain protocols and protocol stacks can be used on each of those networks and network interfaces as described above.

Aforementioned human interface devices, human-accessible storage devices, and network interfaces can be attached to a core 740 of the computer system 700.

The core 740 can include one or more Central Processing Units (CPU) 741, Graphics Processing Units (GPU) 742, specialized programmable processing units in the form of Field Programmable Gate Areas (FPGA) 743, hardware accelerators for certain tasks 744, and so forth. These devices, along with Read-only memory (ROM) 745, Random-access memory 746, internal mass storage such as internal non-user accessible hard drives, SSDs, and the like 747, may be connected through a system bus 748. In some computer systems, the system bus 748 can be accessible in the form of one or more physical plugs to enable extensions by additional CPUs, GPU, and the like. The peripheral devices can be attached either directly to the core's system bus 748, or through a peripheral bus 749. Architectures for a peripheral bus include PCI, USB, and the like.

CPUs 741, GPUs 742, FPGAs 743, and accelerators 744 can execute certain instructions that, in combination, can make up the aforementioned computer code. That computer code can be stored in ROM 745 or RAM 746. Transitional data can be also be stored in RAM 746, whereas permanent data can be stored for example, in the internal mass storage 747. Fast storage and retrieve to any of the memory devices can be enabled through the use of cache memory, that can be closely associated with one or more CPU 741, GPU 742, mass storage 747, ROM 745, RAM 746, and the like.

The computer readable media can have computer code thereon for performing various computer-implemented operations. The media and computer code can be those specially designed and constructed for the purposes of the present disclosure, or they can be of the kind well known and available to those having skill in the computer software arts.

As an example and not by way of limitation, the computer system having architecture 700, and specifically the core 740 can provide functionality as a result of processor(s) (including CPUs, GPUs, FPGA, accelerators, and the like) executing software embodied in one or more tangible, computer-readable media. Such computer-readable media can be media associated with user-accessible mass storage as introduced above, as well as certain storage of the core 740 that are of non-transitory nature, such as core-internal mass storage 747 or ROM 745. The software implementing various embodiments of the present disclosure can be stored in such devices and executed by core 740. A computer-readable medium can include one or more memory devices or chips, according to particular needs. The software can cause the core 740 and specifically the processors therein (including CPU, GPU, FPGA, and the like) to execute particular processes or particular parts of particular processes described herein, including defining data structures stored in RAM 746 and modifying such data structures according to the processes defined by the software. In addition or as an alternative, the computer system can provide functionality as a result of logic hardwired or otherwise embodied in a circuit (for example: accelerator 744), which can operate in place of or together with software to execute particular processes or particular parts of particular processes described herein. Reference to software can encompass logic, and vice versa, where appropriate. Reference to a computer-readable media can encompass a circuit (such as an integrated circuit (IC)) storing software for execution, a circuit embodying logic for execution, or both, where appropriate. The present disclosure encompasses any suitable combination of hardware and software.

Referring now to FIG. 8, an operational flowchart illustrating the steps of a method 800 carried out by a program for splitting viewport bitstreams is depicted.

At 802, the method 800 may include encoding at least partially a first coded video bitstream using a first Group-of-Pictures (GOP) structure at a first resolution.

At 804, the method 800 may include encoding a second coded video bitstream structured into a plurality of tiles using a second GOP structure at a second resolution, wherein the second GOP structure comprises fewer coded pictures than the first GOP structure.

At 806, the method 800 may include creating a streaming bitstream for decoding or rendering using the first coded video bitstream and the second coded bitstream.

It may be appreciated that FIG. 8 provides only an illustration of one implementation and does not imply any limitations with regard to how different embodiments may be implemented. Many modifications to the depicted environments may be made based on design and implementation requirements.

Some embodiments may relate to a system, a method, and/or a computer readable medium at any possible technical detail level of integration. The computer readable medium may include a computer-readable non-transitory storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out operations.

The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch-cards or raised structures in a groove having instructions recorded thereon, and any suitable combination of the foregoing. A computer readable storage medium, as used herein, is not to be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (e.g., light pulses passing through a fiber-optic cable), or electrical signals transmitted through a wire.

Computer readable program instructions described herein can be downloaded to respective computing/processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.

Computer readable program code/instructions for carrying out operations may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the “C” programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects or operations.

These computer readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the flowchart and/or block diagram block or blocks. These computer readable program instructions may also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and/or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including instructions which implement aspects of the function/act specified in the flowchart and/or block diagram block or blocks.

The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions/acts specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer readable media according to various embodiments. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of instructions, which comprises one or more executable instructions for implementing the specified logical function(s). The method, computer system, and computer readable medium may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in the Figures. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the Figures. For example, two blocks shown in succession may, in fact, be executed concurrently or substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts or carry out combinations of special purpose hardware and computer instructions.

It will be apparent that systems and/or methods, described herein, may be implemented in different forms of hardware, firmware, or a combination of hardware and software. The actual specialized control hardware or software code used to implement these systems and/or methods is not limiting of the implementations. Thus, the operation and behavior of the systems and/or methods were described herein without reference to specific software code—it being understood that software and hardware may be designed to implement the systems and/or methods based on the description herein.

No element, act, or instruction used herein should be construed as critical or essential unless explicitly described as such. Also, as used herein, the articles “a” and “an” are intended to include one or more items, and may be used interchangeably with “one or more.” Furthermore, as used herein, the term “set” is intended to include one or more items (e.g., related items, unrelated items, a combination of related and unrelated items, etc.), and may be used interchangeably with “one or more.” Where only one item is intended, the term “one” or similar language is used. Also, as used herein, the terms “has,” “have,” “having,” or the like are intended to be open-ended terms. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.

The descriptions of the various aspects and embodiments have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed. Even though combinations of features are recited in the claims and/or disclosed in the specification, these combinations are not intended to limit the disclosure of possible implementations. In fact, many of these features may be combined in ways not specifically recited in the claims and/or disclosed in the specification. Although each dependent claim listed below may directly depend on only one claim, the disclosure of possible implementations includes each dependent claim in combination with every other claim in the claim set. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, the practical application or technical improvement over technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein. 

What is claimed is:
 1. A method of splitting viewport bitstreams, executable by a processor, comprising: encoding, at least partially, a first coded video bitstream using a first Group-of-Pictures (GOP) structure at a first resolution; encoding a second coded video bitstream structured into a plurality of tiles using a second GOP structure at a second resolution, wherein the second GOP structure comprises fewer coded pictures than the first GOP structure; creating a streaming bitstream for decoding or rendering using the first coded video bitstream and the second coded video bitstream, wherein the streaming bitstream comprises a greater number of random access points than the first coded video bitstream; and transmitting the first coded video bitstream at an actual bitrate that fits a target bitrate in response to a slow change of a user's field of view (FoV).
 2. The method of claim 1, wherein the second coded video bitstream has a shorter segment size than the first coded video bitstream.
 3. The method of claim 2, wherein the second coded video bitstream is associated with the user's field of view (FoV).
 4. The method of claim 3, further comprising: transmitting the first coded video bitstream at the actual bitrate that fits the target bitrate in response to insufficient network bandwidth.
 5. The method of claim 3, further comprising: transmitting the second coded video bitstream in response to a quick change of the user's FoV.
 6. The method of claim 1, further comprising offering for delivery, over Dynamic Adaptive Streaming over HTTP (DASH), at least a one first segment of the first coded video bitstream and a plurality of second segments of the second coded video bitstream, wherein at least one of the second segments includes at least one tile of the second video bitstream but less than the whole second video bitstream.
 7. The method of claim 1, further comprising: upsampling a first picture; and blending the first picture with the second picture in response to the first coded video bitstream and the second coded video bitstream being transmitted and decoded at a decoder, wherein a second picture of the second coded video bitstream covers a part or a whole region of a first picture of the first coded video bitstream.
 8. The method of claim 7, wherein blending the first picture with the second picture further comprises: replacing or averaging the part or the whole region of the first picture by the second picture.
 9. A computer system for splitting viewport bitstreams, the computer system comprising: one or more computer-readable non-transitory storage media configured to store computer program code; and one or more computer processors configured to access said computer program code and operate as instructed by said computer program code, said computer program code including: first encoding code configured to cause the one or more computer processors to encode, at least partially, a first coded video bitstream using a first Group-of-Pictures (GOP) structure at a first resolution; second encoding code configured to cause the one or more computer processors to encode a second coded video bitstream structured into a plurality of tiles using a second GOP structure at a second resolution, wherein the second GOP structure comprises fewer coded pictures than the first GOP structure; creating code configured to cause the one or more computer processors to create a streaming bitstream for decoding or rendering using the first coded video bitstream and the second coded video bitstream, wherein the streaming bitstream comprises a greater number of random access points than the first coded video bitstream; and first transmitting code configured to cause the one or more computer processors to transmit the first coded video bitstream at an actual bitrate that fits a target bitrate in response to a slow change of a user's field of view (FoV).
 10. The computer system of claim 9, wherein the second resolution is higher than the first resolution.
 11. The computer system of claim 10, wherein the second coded video bitstream has a shorter segment size than the first coded video bitstream.
 12. The computer system of claim 11, wherein the second coded video bitstream is associated with the user's field of view (FoV).
 13. The computer system of claim 12, further comprising: second transmitting code configured to cause the one or more computer processors to transmit the first coded video bitstream at the actual bitrate that fits the target bitrate based on insufficient network bandwidth.
 14. The computer system of claim 12, further comprising: third transmitting code configured to cause the one or more computer processors to transmit the second coded video bitstream based on a quick change of the user's FoV.
 15. The computer system of claim 9, wherein the streaming bitstream is structured with a reduced random-access point period.
 16. The computer system of claim 9, further comprising: offering code configured to cause the one or more computer processors to offer for delivery, over Dynamic Adaptive Streaming over HTTP (DASH), at least a one first segment of the first coded video bitstream and a plurality of second segments of the second coded video bitstream, wherein at least one of the second segments includes at least one tile of the second video bitstream but less than the whole second video bitstream.
 17. The computer system of claim 9, further comprising: upsampling code configured to cause the one or more computer processors to upsample a first picture; and blending code configured to cause the one or more computer processors to blend the first picture with the second picture based on the first coded video bitstream and the second coded video bitstream being transmitted and decoded at a decoder, wherein a second picture of the second coded video bitstream covers a part or a whole region of a first picture of the first coded video bitstream.
 18. The computer system of claim 17, wherein the blending code further comprises: respective replacing and averaging code configured to cause the one or more computer processors to replace or average the part or the whole region of the first picture by the second picture.
 19. A non-transitory computer readable medium having stored thereon a computer program for splitting viewport bitstreams, the computer program configured to cause one or more computer processors to: encode, at least partially, a first coded video bitstream using a first Group-of-Pictures (GOP) structure at a first resolution; encode a second coded video bitstream structured into a plurality of tiles using a second GOP structure at a second resolution, wherein the second GOP structure comprises fewer coded pictures than the first GOP structure; create a streaming bitstream for decoding or rendering using the first coded video bitstream and the second coded video bitstream, wherein the streaming bitstream comprises a greater number of random access points than the first coded video bitstream; and transmit the first coded video bitstream at an actual bitrate that fits a target bitrate in response to a slow change of a user's field of view (FoV).
 20. The computer readable medium of claim 19, wherein the computer program is further configured to cause the one or more computer processors to: transmit the second coded video bitstream based on a quick change of the user's FoV, wherein the second resolution is higher than the first resolution, wherein the second coded video bitstream has a shorter segment size than the first coded video bitstream, and wherein the second coded video bitstream is associated with the user's field of view (FoV). 